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Abstract 

This pearl aims to demonstrate the ideas of wholemeal and projec¬ 
tive programming using the Towers of Hanoi puzzle as a running 
example. The puzzle has its own beauty, which we hope to expose 
along the way. 

Categories and Subject Descriptors D.1.1 [Programming Tech¬ 
niques ]: Applicative (Functional) Programming; D.3.2 [Program¬ 
ming Languages ]: Language Classifications—Applicative (func¬ 
tional) languages, Haskell; D.3.3 [Programming Languages ]: 
Language Constructs and Features—Frameworks, patterns, recur- 

General Terms Algorithms, Design, Languages 
Keywords Towers of Hanoi, wholemeal programming, projective 
programming, Hanoi graph, Sierpinski graph, Sierpinski gasket 
graph. Gray code 

1. Introduction 

Functional languages excel at wholemeal programming, a term 
coined by Geraint Jones. Wholemeal programming means to think 
big; work with an entire list, rather than a sequence of elements; de¬ 
velop a solution space, rather than an individual solution; imagine 
a graph, rather than a single path. The wholemeal approach often 
offers new insights or provides new perspectives on a given prob¬ 
lem. It is nicely complemented by the idea of projective program¬ 
ming: first solve a more general problem, then extract the interest¬ 
ing bits and pieces by transforming the general program into more 
specialised ones. This pearl aims to demonstrate the techniques us¬ 
ing the popular Towers of Hanoi puzzle as a running example. This 
puzzle has its own beauty, which we hope to expose along the way. 

2. The Hanoi graph 

The Towers of Hanoi puzzle was invented by the French number 
theorist Edouard Lucas more than a hundred years ago. It consists 
of three vertical pegs, on which discs of mutually different diame¬ 
ters can be stacked. For reference, we call the pegs A, B and C and 
let a, b and c range over pegs. 

data Peg = A | B | C 

I own a version of the puzzle where the pegs are arranged in a row. 
However, the mathematical structure of the puzzle becomes clearer, 
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if we arrange them in a circle. Initially, the discs are placed on one 
peg in decreasing order of diameter. The task is then to move the 
disks, one at a time, to another peg subject to the rule that a larger 
disk must not be placed on a smaller one. 

This restriction implies that a configuration can be represented 
by a list of pegs: the first element determines the position of the 
largest disc, the second element the position of the second largest 
disc, and so forth. Consequently, there are 3” possible configura¬ 
tions where n is the total number of discs. Lucas’ original puzzle 
contained 8 discs. The instructions of the puzzle refer to an old 
Indian legend, attributed to the French mathematician De Parville, 
according to which monks were given the task of moving a total 
of 64 discs. Since the day of the world’s creation, they transfer the 
discs, one per day. According to the legend, once they complete 
their sacred task, the world will come to an end. 

Now, taking a wholemeal approach, let us first develop the 
big picture. The set of all configurations together with the set 
of legal moves defines a graph, which turns out to enjoy a nice 
inductive definition. If there are no discs to move around, the graph 
consists of a singleton node: o. For the inductive step we reason as 
follows: the largest disc can only be moved, if all the smaller discs 
reside on one other peg. The smaller discs, however, can be moved 
independent of the largest one. As the largest disk may rest on one 
of three pegs, the graph for n + 1 discs consequently incorporates 
three copies of the graph for n discs linked by three edges. The 
diagram in Fig. 1 illustrates the construction. The graph has the 
shape of a triangle; the dashed lines indicate the sub-graphs (for 
n = 0 the sub-graphs collapse to singleton nodes); the three solid 
lines connect the sub-graphs. The inductive construction shows that 



AC" CA n 

AA" ---AB n — CB n ---CC n 


Figure 1. Inductive construction of the Hanoi graph. 

the graph is planar; it can be drawn so that no edges intersect. Fig. 2 
displays the graph for 4 discs. To reduce clutter, the peg of the 
largest disc is always written in the centre of the respective sub¬ 
graph, with the size of the font indicating the size of the disc. Can 
you find the configuration [B, A, B, c] ? The comers of the triangle 
correspond to perfect configurations: all the discs reside on one 
peg. The example graph shows that every configuration permits 
three different moves, except for the three perfect configurations, 
where only two moves are possible. 




Figure 2. The Hanoi graph for 4 discs. 


Let us turn our attention to the layout of the sub-graphs. The fol¬ 
lowing notation proves to be useful: the arrangement x y z denotes 
a permutation of x, y and 2, which by assumption are pairwise dif¬ 
ferent. Using a h c to indicate the position of the largest disc—the 
largest disc in the left triangle resides on a and so forth—we ob¬ 
serve that if the comers of the graph are a b c , then the comers of the 
sub-graphs are a c b, c b a and /, " ,, respectively. Using this observa¬ 
tion, we can capture the informal description of the construction as 
a pseudo-Haskell program. 

graph „ („\.) — <■' 

graph n+1 ( a h c ) = b <1 graph n ( c 6 a) 

/ \ 

a < graph n ( a c b ) — c < graph n ( b a c ) 

The function graph n maps an arrangement „ b , to an undirected 
graph, whose vertices are lists of pegs of length n. The notation 
a < g means prepend a to all the vertices of g\ o denotes a 
singleton node labelled with the empty list. We leave the type of 
graphs unspecified. If the type were a functor, then a < g would be 
fmap (a :) g. The call graphs (a b c) yields the graph in Fig. 2. 

A few observations are in order. The definition of graph n im¬ 
plies that the graph has 3" nodes (ao = 1, a n +1 = 3 • a„ ) and 
(3 n+1 — 3)/2 edges (ao = 0, a„+1 = 3 • a„ + 3). Furthermore, the 
length of a side of the triangle is 2" — 1 (ao = 0, a„+i = 2 • a n + 1). 
Since there are only 3! = 6 permutations of three different items, 
the graph contains at most six different mini-triangles: a B c, c A b, 
b C a, a C b, c b a and b A c- Note that the first three arrange the 
pegs clockwise and the last three counterclockwise. Inspecting the 
definition of graph n , we see that the direction changes with every 
recursive step. The diagram in Fig. 3 illustrates the change of di¬ 
rection. This observation implies that the recursion pattern is quite 
regular: at any depth there are only three different recursive calls. 
Fig. 4 visualises the call structure using three different colours. 


Figure 3. Change of direction. 


3. Towers of Hanoi, recursively 

Solving the Towers of Hanoi puzzle amounts to finding a shortest 
path in the corresponding graph. Clearly, the shortest path between 
two comers is along the side of the triangle. Projecting onto the 
lower side, we transform graph n to 

hanoi'o ( a b c ) = [[]] 

hanoi' n+1 a < hanoi' n ( a c b ) + c <1 hanoi' n (b a c) ■ 

Now, a < x is shorthand for fmap ( a :) x. The call hanoi' n ( a b c ) 
returns a list of configurations solving the problem of ‘moving n 
discs from a to c using b\ 

Instead of configurations (vertices of the graph) we can alterna¬ 
tively return a list of moves (corresponding to edges). 

hanoio ( a 6 c ) = [] 

hanoi n +i ( a b c ) = hanoi n ( a c b ) + [(a, c)] + hanoi„ (b a c) 
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Figure 4. Call structure of Hanoi at recursion depth 4. 


The pair (a, c) represents the instruction ‘move the topmost disc 
from a to c’. Here is the sequence of moves for n = 4: 

» Hanoi 4 (a b c) 

[(A, B), (A, C), (B, C), (A, B), (C, A), (C, B), (A, B), (A, C), 
(B, C), (B, A), (C, A), (B, C), (A, B), (A, C), (B, C)j . 

Note that the lower part of the list can be obtained from the upper 
part via a clockwise rotation of the pegs: a c b becomes b a c- 

There is at least one further variation: instead of an arrangement 
one can pass a source and a target peg. 
hanoio a c = [] 
hanoin+i a c 

= hanoin a (a _L c) + [(a, c)] + hanoi n (a ± c) c 
The function _L, which determines ‘the other peg’, is given by 

A _L A = A; A±B = C; A±C = B 
B±A = C; B±B = B; B±C = A 
C _L A = B; C _L B = A; C_LC = C. 

We will find some use for ± later on. For the moment, we just 
note that the operation is commutative and idempotent, but not 
associative. 

4. Towers of Hanoi, parallelly 

Imagine that the monastery always accommodates as many monks 
as there are discs. The tallest monk is responsible for moving 
the largest disc, the second tallest monk for moving the second 
largest disc, and so forth. Can we set up a work schedule for the 
monastery? 

Inspecting Fig. 2, we notice that, somewhat unfairly, the small¬ 
est monk is the busiest. Since the smallest triangles correspond to 
moves of the smallest disc, he is active every other day. We can ex¬ 


tract his work plan from hanoi n by omitting all the moves, except 
when n equals 1. 

cycle 0 (A) = [] 

cycle 1 (A) = [(a,c)] 

cycle n+1 (A) = cycle n ( a c b ) + cycle n ( b a c ) 

The function is called cycle, because the smallest disc cycles 
around the pegs: in the recursive call it is moved from a to b 
and then from b to c. Whether it cycles clockwise or counterclock¬ 
wise depends on the parity of n —the direction changes with every 
recursive call of cycle. 

Of course, the smallest disc is by no means special: all the discs 
cycle around the pegs, albeit at a slower pace and in alternating 
direchons. In fact, hanoi satisfies the following ‘fractal’ property: 

hanoin+i ( a b c) = cycle n+x (A) Y hanoi„ ( a b c ) , (1) 

where Y denotes the interleaving of two fists. 

[] Y bs = bs 

(a : as) Y bs — a : (bs Y as) 

The fractal property suggests the following alternative definition of 
hanoi , which has a strong parallel flavour. 

phanoi 0 (A) = [] 

phanoi n+1 (A) = cycle n+1 (A) Y phanoi n (A) 

In words, the smallest monk starts to work on the first day; he is 
active every second day and moves his disc, say, clockwise around 
the pegs. The second smallest monk starts on the second day; he 
is active every fourth day and moves his disc counterclockwise. 
And so forth. Actually, only the smallest monk must remember the 
direchon; for the larger discs there is no choice, as one of the other 
two pegs is blocked by the smallest disc. 






There is an intriguing cross-connection to binary numbers: the 
activity diagram of the monks (Which monk has to work on a given 
day?) 

discso = [] 

discs n +1 = discsn + [n] HI- discs n 
yields the binary carry sequence or ruler function as n goes to 
infinity (Hinze, 2008). This sequence gives the number of trailing 
zeros in the binary representations of the positive numbers, most 
significant bit first. Or put differently, it specifies the running time 
of the binary increment. We will make use of this observation later 

The fractal property (1) enjoys a simple inductive proof, which 
makes essential use of the following abide law. If x\ and .2:2 are of 
the same length, then 

(zi + t/i) Y (x 2 HI- 2/2) = {xi Y x 2 ) + ( yi Y y 2 ) . 

The basis of the induction is straightforward. Here is the inductive 
step. 

cycle n+2 (A) Y hanoi n+ 1 (A) 

= { definition of cycle and definition of hanoi } 

{cycle n+1 { a c b ) + cycle n+1 (& a c )) 

Y ( hanoi n { a \) + [(a, c)] + hanoi n ( 6 a c )) 

= { abide law } 

{cycle n+1 { a c b) Y hanoi n ( a c b)) + [(a, c)] 
+(cycle n+1 (t“c) Y hanoi„ (& a c )) 

= {ex hypothesi } 

hanoin+i ( a C b ) + [(a, c)] + hanoi„+ 1 (t“ c ) 

= { definition of hanoi } 

hanoi H . 1-2 (a c) 

The abide law is applicable in the second step, because the two 
lists, cycle n+1 { a c b) and hanoi n { a c b) Hb [(a, c)], have the 
same length, namely, 2 n . Speaking of the length of lists, note 
that 2 n+1 — 1 — 52"_o 2* is a simple consequence of the fractal 
property. 

5. When will the world come to an end? 

Many visitors come to the monastery. Looking at the configuration 
of discs, they often wonder how many days have passed since the 
creation of the world. Or, when will the world come to an end? 

We can answer these questions by locating the current config¬ 
uration in the Hanoi graph. If we use as positions the three digits 
o 2 i—that is, 0 for the left triangle, 2 for the upper triangle and 1 
for the right triangle—then we obtain the answer to the first ques¬ 
tion in binary. Fig. 5 displays the Hanoi graph for 4 discs suit¬ 
ably re-labelled—this graph is also known as the Sierpinski graph. 
The 2 4 nodes on the lower side of the triangle, and only those, are 
labelled with binary numbers. Consequently, if the current position 
contains a 2, we know that the monks have lost track. (To answer 
the second question, we use as positions i 2 o instead of o 2 i. If we 
are only interested in the distance to the final configuration, we 
simply replace the digit 2 by a 1.) 

pos (A) [] = [] 

pos (A) {p ■■ PS ) 

| p -- a = 0 : pos { a c b) ps 
| p =}jj» = 2 : pos (A) ps 
I p =1 : pos (b a c ) ps 

For instance, pos (a b c) [A, B, C,A] yields [0,1,0,1], the bi¬ 
nary representation of 5, most significant bit first. The function 
pos { a b c) defines a hijection between {A, B, C} n and {0, 2, l} n 


for any given initial arrangement a b c . This arrangement can be seen 
as representing the bijective mapping (a 1—>■ 0, 6 1—>■ 2, c 1—>■ 1}. Al¬ 
ternatively, we can use an arrangement, say, / ! r as a representation 
of the ‘inverse’ mapping {A 1—> l, B 1—> t , C 1—> r} obtaining the 
following slightly more succinct variant of pos. 

pos' (A) [] = [] 

pos' {i* r ) (A : ps) = l : pos' (; r t) ps 

pos' {t'r) (B : ps) = t : pos' { r *l) ps 

pos' ((* r ) (C : ps) = r : pos 1 {t l r ) ps 

The two variants are related by pos (a b c) = pos 1 (o 2 i). The 

latter definition is particularly easy to invert. 


conf {a 

c) 

= [] 



conf {a 

c) (0 

ps) = a 

conf { a 

b) ps 

conf {a 1 

'’<=) (2 

ps) = b : 

conf {c l 

’a) PS 

conf {a 1 

k c) (1 

ps) — c : 

conf 

*c) PS 


The call conf (a b c) [0,1,0,1] yields [A, B, C, A], the configu¬ 
ration we obtain after 5 days. The functions pos' and conf are actu¬ 
ally identical, if we identify A with 0, B with 2 and C with 1. Then 
pos' is an involutive graph isomorphism between Hanoi graphs and 
Sierpinski graphs of the same order. 

If the monks have lost track—a 2 appears in the answer list— 
then we can use the idea of locating a configuration in the Hanoi 
graph to determine the shortest path to the final configuration c n . 
This leads to the following generalised version of hanoi. 


ghanoi 0 

[] (A)4$| 

ghanoi H+1 

(p : p s ) (A) 

1 P- a 

= ghanoi n P s + [(«, c)] + hanoi„ {b a c) 

\p----b 

= ghanoin P s (&“<*) + [(&, c)] HI- hanoi n (A) 

1 P f- 

= ghanoi n P s (A) 

(The index n 

is actually redundant: it always equals the length of 


the peg list.) Depending on the location of p, we either walk within 
the left triangle and then along the lower side, or within the upper 
triangle and then along the right side, or within the right triangle. 
The reader should convince herself that ghanoi n ps (A) indeed 
yields the shortest path between ps and c". Note that the first two 
equations are perfectly symmetric, in fact, ghanoi n ps { a b c ) = 
ghanoi n P s ( b a c )• As an aside, if we fuse ghanoi with length, 
then we obtain a function that yields the distance to the final 
configuration. 

6. Towers of Hanoi, iteratively 

The generalised version of the puzzle—moving from an arbitrary 
configuration to a perfect configuration—serves as an excellent 
starting point for the derivation of an iterative solution, that is, a 
function that maps a configuration to the next move or to the next 
configuration. 

The next move is easy to determine: we fuse ghanoi with the 
natural transformation 

first :: [a] —> Maybe a 

first [] = Nothing 

first {a : asfAJust a 

that maps a list to its first element. We obtain 

move 0 [] (<A) = Nothing 

move n +i {p : ps) (A) 

| p -- a = move n ps („ c &) + Just{a, c) + first{hanoi„{b a c )) 

| p -- b = move n ps {b c a) + Just{b, c) + first{hanoi„{ a b c )) 

| p — \(i— move n ps (A) ■ 





2 



Figure 5. The Sierpinski graph of order 4. 


The operator + is overloaded to also denote concatenation of 
Maybe values (+ is really the mplus method of MonadPlus). 
(+) :: Maybe a —> Maybe a —> Maybe a 

Nothing + m = m 
Just a + m = Just a 

We can simplify the definition of move drastically: since Just a + 
m = Just a, the calls to hanoi can be eliminated; because of 
that the index n is no longer needed. Furthermore, the first two 
equations can be unified through the use of X, the operator that 
determines ‘the other peg’. Finally, the second argument, a b c, can 
be simplified to c, the target peg. 

move [ ] c = Nothing 
move (p : ps) c 

| p c = move ps (p X c) + Just (p, c) 

I P c = move ps c 

Here is a short interactive session that illustrates the use of move. 
» move [A, B, B, A, C, C, C, B] C 
Just (B, C) 

» move [A, B, B, A, C, C, C, C] C 
Just (A, B) 

» move [C, C, C, C, C, C, C, C] C 
Nothing 

Since the pair (B, C) means ‘move the topmost disc from peg B 
to peg C, the configuration following [A, B, B, A, C, C, C, B] is 
[A,B,B,A,C,C,C,C]. Incidentally, if we start with the initial 
peg list [A, A, A, A, A, A, A, A] and target C, we obtain these 
configurations after 110 and 111 steps. 

The function move implements a two-way algorithm: on the 
way down the recursion it calculates the target peg for each disc 
(using X); on the way up the recursion it determines the smallest 
disc that is not yet in place (using +). The following table makes 


the target pegs explicit. The rows labelled c, lists the target peg for 
each disc: the first, user-supplied target is Co = C, the next target 
is ci = po -L Co, and so forth. 

i 0 1 2 3 4 5 6 7 

110 P i A B B A C C C B 

d CBBBCCCCA 

111 pi A B B A C C C C 

d CBBBCCCCC 

The smallest disc is not in place, so it is moved from B to C. In the 
next round, disc 3 has to be moved from A to B. 

The smaller discs are moved more frequently, so it is actually 
prudent to reverse the list of pegs so that the peg on which the 
smallest disc is located comes first. The situation is similar to the 
binary increment: visiting the digits from least to most significant 
bit is more efficient than the other way round. Let us assume for 
the moment that we know the ‘last target’, the value of c that is 
discarded in the first equation of move (the pegs that stick out in 
the example above). Since X is reversible, p± c = c' iff c = p±c', 
we can reconstruct the previous target c from the next target c'. 
The following variant of move makes use of this fact—the suffix 
‘i’ indicates that the input list is now arranged in increasing order 
of diameter. 

movei [] c' = Nothing 
movei (p : ps) c' 

| p ^ (p _L c') = Just (p, p X c') + movei ps (p X c') 

| p -- (p X c') = movei ps d 

We consistently changed the second argument of move to reflect 
the fact that we compute the previous from the next target and 
additionally replaced the remaining occurrences of c by p X c'. 
Again, we can simplify the code: p / (p X c ) is the same as 
p -J- c'. Applying Just a + m = Just a once more, we can 
eliminate the first recursive call to movei so that the function 






stops as soon as the smallest displaced disc is found—this was the 
purpose of the whole exercise. We obtain 

movei [] c' = Nothing 
movei (p : ps) d 

I p yt= c' = Just ( p, p ± c') 

| p -- c' = movei ps d . 

In a nutshell, movei determines the smallest disc that does not 
reside on the last target. 

So, for an iterative version of hanoi we have to maintain two 
pieces of information: the current configuration and the current ‘last 
target’. It remains to determine the initial last target and how the 
last target changes after each move. If the list of pegs is given in the 
original decreasing order, then we can transform move to 

last [] c = c 

last (p : ps) last ps (p ± c) , 

which yields the last target. It is not hard to see that last is an 
instance of the famous foldl: last ps c = foldl (±) c ps. If 
we reverse the list, we simply have to replace foldl by foldr addi¬ 
tionally using the fact that ± is commutative: foldr (±) c ps = 
foldl (±) c (reverse ps). 

Next, we augment movei so that it returns the next configura¬ 
tion instead of the next move and additionally the next ‘last target’. 

step ([], d) = Nothing 
step (p : ps,d) 

\p-^d = Just ((p ± d) : ps, p ± d) 

| p -- d = do {( ps c) <— step (ps, d); 

return (p : ps',p ± c)} 

Consider the second equation: p is moved to p _L d. After the move, 
the disc resides on the target peg. Consequently, the next target is 
also p ± d —recall that ± is idempotent. This target is then updated 
in the third equation ‘on the way back’ mimicking move’s mode of 
operation. The function step runs in constant amortised time, since 
it performs the same number of steps as the binary increment— 
recall that the activity diagram of the monks coincides with the 
binary carry sequence. 

The next last target can, in fact, be easily calculated by hand. 
Consider the following two subsequent moves (as usual, a, b and c 
are pairwise different). 

1 n — 2 1 0 


b a ••• b a b 

Assume that the first configuration ends with an even number of cs. 
The topmost disc of a is then moved to b. The new succession 
of target pegs consequently alternates between b and a: since the 
number of cs is even, the new last target is b; for an odd number, 
it is a. So, the monks can be instructed as follows: determine the 
smallest disc that is not on c. Transfer it from a to b. If the disc’s 
number is even, the new last target is b; otherwise, it is a. 

If we solve the original puzzle, that is, if the configurations lie 
on one of the sides of the triangle, then the next last target is even 
easier to determine: like the discs, it cycles around the pegs. If the 
pegs are arranged a b c and we move the discs from A to C, then 
the last target moves counterclockwise for an even number of discs 
and clockwise for an odd number. 



Summing up, we obtain the following iterative implementation 
for solving the generalised Hanoi puzzle. 

ihanoi ps c = map fst (iterate step (ps, foldr (±) c ps)) 
iterate :: (a —> Maybe a) —► (a —> [a]) 
iterate f x = x : case f x of { Nothing —> [ ]; 

Just x ' —> iterate f x ’} 


7. Longest paths and Sierpinski’s triangle 

So far we have considered shortest paths in the Hanoi graph. Since 
the destruction of the world hangs in the balance, as a gift to 
future generations, we might want to look for the longest path. 
In the following variant of hanoi the largest disc makes a detour. 
(According to the Indian legend, the temple is actually in Bramah 
rather than in Hanoi, hence the name of the function.) 
bramaho (a b c) = [] 


bramah n +i ( a b c) 


bramahn ( a b c) + [(a, &)] 
bramahn ( c b a) + [(&, c)] 
bramah n (a b c) 


The largest disc is first moved from a to b, and then from b to c. 
Since bramah n returns 3 n — 1 moves (ao = 0, a n +i = 3 • a„ + 2), 
we have actually found a Hamiltonian path. The path has another 
interesting property: if the pegs are arranged in a row, abc, then 
discs are only moved between adjacent pegs. 

The Hamiltonian path for four discs is displayed in Fig. 6. The 
picture is quite appealing. Actually, if we move the sub-triangles 
closer to each other so that the comers touch, we obtain a nice frac¬ 


tal image. Fig. 7 shows the result for 7 discs. The corresponding 
graph is known as the discrete Sierpinski gasket graph. 1 The pic¬ 
ture has been drawn using Functional Metapost’s turtle graphics 
(Korittky, 1998). 


curveo d = forward & turn (2 * d) & forward 
curve„+i d = turn d & curve n (—d) & turn d & cwrve n d 
& turn d & curve n (—d) & turn d 


The command forward moves the turtle one step forward, turn d 
turns the turtle clockwise by d degrees, and & sequences two 
turtle actions. Since turtle graphics is state-based—the turtle has 
a position and faces a direction—recursive definitions typically 
maintain an invariant. To draw the ‘triangle’ a b c, we start at a 


looking at b and stop at c looking away from b. The overall change 
of direction is twice the second argument of curve, which for 
equilateral triangles is either 60° or —60°. 

The curve is closely related to Sierpinski’s arrowhead curve. In 
fact, both curves yield Sierpinski’s triangle as n goes to infinity. 
As an aside, Sierpinski’s triangle is a so-called fractal curve: it has 
the Hausdorff dimension log 3/ log 2 = 1.58496, as it consists of 
three self-similar pieces with magnification factor 2. 


8. Gray code 

The function bramah enumerates the configurations {A, B, C}" 
changing only one peg at a time. In other words, the succession of 
configurations corresponds to a ternary Gray code! To investigate 
the correspondence a bit further, here is a version of bramah that 
returns a list of configurations, rather than a list of moves. 
bramah' 0 (a 6 i|»[[]] 
bramah' n+ i ( a 6 «*i a < bramah! n ( a b c) 

+ b < bramah' n (c b a) 

+ c <1 bramah'n ( a b c ) 







There are two standard ternary Gray codes: the so-called modular 
code, the digits vary 012|201| 120 - - and the reflected code, the 
digits vary 012|210|012 • • •. The definition above yields the latter, 
as the discs are only moved between adjacent pegs. In fact, we have 
bramah'n ( c 6 a) = reverse ( bramah' n ( a 6 c))- Using this property 
on the second recursive call, we can simplify bramah' n (o 1 2) 
somewhat. 
grayS 0 = [[]] 

grayS n+1 = 0 < grayS n + 1 < reverse grayS n + 2 < grayS n 
For comparison, here is the definition of the Gray binary sequence. 
gray2 0 = [[]] 

gray 2,,^ = 0 < gray2 n + 1 < reverse gray2 n 

Actually, the binary Gray code is also hidden in the Tower of 
Hanoi puzzle. We only have to work with a different configuration 
space: instead of {A, B, C}" we use {0,1}" keeping track whether 
a disc has been moved an even or an odd number of times. The 
initial configuration A A" becomes 00", the final configuration 
CC" becomes 10". Since the ith disc is moved 2* times, all the 
discs make an even number of moves, except for the largest, which 
makes a single move. 

We can easily adapt ihanoi to generate binary Gray code. We 
take as a starting point the first definition of movei, slightly mod¬ 
ified so that the next configuration is returned instead of the next 
move (we also applied the Just a + m = Just a simplification). 
configi [ ] c' = Nothing 
configi (p : ps) d 

I P S- (j> -L c') = Just {p±c' : ps) 

\p----(p±c') =p< I configi ps (p J_ c') 

Now, the Gray code equivalent of _L is the Boolean operation 
exclusive or, that is, inequality of Booleans. This implies that the 
last target c! corresponds to a parity bit. Thus, configi becomes 
(the code uses Booleans rather than bits) 
codei [] p = Nothing 
codei (b : bs) p 

\ b(bp) = Just ((b p) : bs) 

| b =s tjb £ p) = b < codei bs (b ^ p) . 

Again, we can simplify the code a bit: inequality and equality of 
Boolean values are associative (Backhouse and Fokkinga, 2001), 
so b ^ (b ^ P) is simply p. Using False b = b and 
True d 2 b = -> b, we obtain 

codei [] p = Nothing 
codei [b : bs) p 

| p = Just (-i b : bs) 

j -i p = b < codei bs b . 

In words: we traverse the list p : bs up to the first 1; the following 
bit, if any, is flipped. 

As for ihanoi, we have to maintain two pieces of information: 
the current Gray code and the current parity bit. The latter is easy 
to update: it is flipped in each step. Summing up, we obtain the 
following Gray code generator. 

igray bs = map fst (iterate step ( bs,foldr (^) True bs)) 
where step ( bs,p ) = do {bs 1 <— codei bs p; 

return (bs 1 p)} 

This is, in fact, the functional version of Knuth’s Algorithm G 
(2005). 

9. Conclusion and further reading 

We have come to the end of the Tour D’Hanoi. In the spirit of the 
wholemeal approach we started with an inductive definition of the 


Hanoi graph. From that we derived a series of programs evolving 
around the Tower of Hanoi theme. Knowing the big picture was 
jolly useful: for instance, calculating the number of moves could 
be reduced to the problem of locating a configuration in the graph. 
Projective program transformations are abundant: hanoi is derived 
from graph by projecting onto the lower side of the graph, cycle is 
derived from hanoi by mashing out the moves of the larger discs, 
and so forth. 

The transformations could be made rigorous within the Algebra 
of Programming framework (Bird and de Moor, 1997). Occasion¬ 
ally, this comes at an additional cost. For instance, to derive cycle 
from hanoi we would additionally need the disc number, which is 
not present in hanoi ’s output. 

A lot is left to explore. There are literally hundreds of papers 
on the subject: Paul Stockmeyer’s comprehensive bibliography has 
a total of 369 entries (2005). From that bibliography I learned that 
my definition of the Hanoi graph is not original: Er introduced it to 
analyse the complexity of the generalised Tower of Hanoi problem 
(1983). The original instructions of the game already alluded to the 
recursive procedure for solving the puzzle. It has been used since 
to illustrate the concept of recursion. The parallel version—usually 
classified as iterative— is due to Buneman and Levy (1980). Back¬ 
house and Fokkinga (2001) show that each disc cycles around the 
pegs exploiting the associativity of equivalence. To the best of the 
author’s knowledge the iterative, or stepwise variant is original. The 
connection to Gray codes has first been noticed by Gardner (1972). 
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